Computer networks such as the Internet allow computer systems to exchange data or content in a variety of ways. One popular technique for accessing content over a computer network such as the Internet uses a suite of protocols commonly referred to as the world wide web. In a typical operation of the world wide web, a user at a client computer system operates a software application called a web browser to access content served by a web server computer system over the computer network. The content may be any type of data or information such as documents, web pages, streams of audio or video data or the like. In particular, a user can request content from a web server by selecting or clicking a hyperlink that the web browser displays on the client computer system (e.g., within a graphical user interface). This operation causes the web browser to reference a uniform resource locator or URL which identifies, among other things, a communications protocol that the browser is to use to access the content, an network address or domain name (e.g., web site name) associated with a computer system (i.e., a web server) that the browser is to communicate with in order to retrieve the content, and the file name, path or other specific reference to the content or data itself. The web browser can use the URL information to send a content request over the network to the computer system that stores the content in order to have a computer system return the content to the web browser.
In many situations, a URL contains the domain name of the computer system that the request for content is to be directed towards rather than the actual network address (e.g., IP address) of the specific web server computer system can serve the content. As an example, a URL such as http://www.cisco.com/content.html indicates that the HTTP protocol is to be used to access content referred to as “content.html” from a computer system associated with the domain name “www.cisco.com.” The name www.cisco.com is referred to as a domain name. Before a web browser can transmit a content request containing this URL to a computer system associated with the www.cisco.com domain name, the web browser must use another system called the domain name system or DNS to convert or “resolve” the domain name www.cisco.com into a network address (e.g., an IP address) of a specific computer system associated with that domain name that can receive and service the client request for the content.
To resolve a domain name into a network address, the web browser passes the domain name www.cisco.com in a domain resolution request over the network to a domain name server computer system (DNS server) associated with the client computer system (e.g., associated with the LAN or network in which the client operates). This domain name server is referred to as a client's DNS proxy server since it resolves domain names on behalf of the client. The client's DNS proxy server can consult a database of formerly resolved domain names (i.e., former conversions of domain names to network addresses done on behalf of this client or other clients) to determine if a mapping of a network address is locally available for the requested domain name to be resolved. If no network address mapping is available locally within the client's DNS proxy server, the client's DNS proxy server uses a DNS protocol to propagate the domain name resolution request over a network such as the Internet to another (one or more) DNS server that may be capable of resolving the domain name into a network address.
Eventually, a DNS server that is capable of resolving the domain name into a network address responds to the DNS request from the client's DNS proxy server and provides a DNS address resolution response that contains the requested network address of a computer system for that domain name (e.g., the network address of a computer within the www.cisco.com domain). The client's DNS proxy server then returns the requested network address back to the web browser operating within the client computer system. The web browser operating on the client computer system can receive the network address provided from that client's DNS proxy server and can use this address to provide a content request for the content associated with the hyperlink to a network device located at that network address. In other words, once the web browser obtains the network address of the web site using DNS, the web browser provides the URL to the web site in the form of a content request directed to the network address resolved by the DNS system. The computer system or other device on the network (e.g., on the Internet) that has that network address will receive the content request from the client computer system and will process the content request accordingly to return the requested content to the client.
A typical web site might have more than one web server computer system capable of providing or serving the content requested in a content request sent from a client computer system. Accordingly, a data communications device such as a load balancer on the network can be configured with the network address of the web site. Data communications devices such as routers and switches within the Internet thus route the content request to the load balancer device that is associated with (i.e., is configured with) the network address of the web site. The load balancer device can then perform a server selection operation based on the content request in order to select a specific web server computer system to handle the processing associated with the content request. The load balancer then forwards the content request to the selected web server computer system for processing. That web server can then obtain the requested content and can provide a content response containing the content over the network back to the web browser operating within the client computer system. In this manner, the web browser can present the content to the user.
In some situations however, a load balancing device for a group of web servers associated with a web site may determine that a content request received from a client is to be handled by another group of servers associated with the web site that may be located in another part of the network. As an example, perhaps load balancing issues indicate that servers associated with the load balancer at this location are heavily loaded and thus the content request should be redirected to another web server at another location. This decision might be made either by the load balancer for a group of servers or may be made by an individual web server computer system. In either case, a device can redirect a client request, such as an HTTP GET request, to another location (e.g., to an address of another load balancer for another group of servers, or to another web server computer system) by responding to the initial content request with an HTTP redirect response. The HTTP redirect response specifies an alternative URL which the web browser is to reference in order to obtain the requested content. When a web browser receives such a redirect response, it performs the processing explained above on the new URL specified within the redirect response in order to again attempt to obtain the content from another device (e.g., from another load balancer device associated with another group of servers or from another web server specifically identified within the redirect response. This may involve performing another domain name resolution for a different domain name specified in the redirect URL prior to transmitting a new content request for the redirected URL.
In this manner, one web server (or another network device such as a load balancer) can redirect content requests to other web servers (or to other network devices such as web caches). This redirection is generally transparent to the user of the web browser and can take place more than once until a particular web server receives the request and serves the requested content back to the web browser. At this point, the web browser receives the content and presents the content to the user at the client computer system.
Another conventional technology related to the present invention relates to content distribution networks. Generally, a content distribution network or CDN is a collection of computer systems (e.g., web servers and one or more load balancers) that are capable of providing content to client computer systems. The various portions of content may be related in some manner, such as being provided by a single content provider. A CDN typically includes a content router (e.g., operating as a load balancer) and one or more content engines that operate as servers (e.g., web servers) to serve content requested by content requests sent from client computer systems to the content router. The content router decides which content engine is to service particular requests for content.
As an example of the operation of a CDN, a user controlling a web browser operating on a client computer system may select a URL that references content served by a content engine within a CDN. The domain name specified in the URL might generally reference the CDN itself, such as www.CDN.com. As explained above, when the web browser uses DNS to resolve this domain name, the content router associated with the CDN can operate as a DNS server on behalf of this CDN domain. As such, when the content router receives, via the DNS system, a domain resolution request to resolve the domain name www.CDN.com into a network address, the content router can select a network address of a specific content engine within the CDN based on routing criteria such as load balancing considerations between the various content engines that might be available to service a content request for content associated with this domain. The CDN content router can return the network address of the selected content engine associated with that CDN to the web browser. As explained above, the web browser can then proceed to access the requested content from that content engine (e.g., operating as a web server) using a protocol such as HTTP.
Some content distribution networks may have large amounts of content that must be distributed for access by clients over a computer network such as the Internet. In addition, organizations that provide CDNs might have limited computing system resources available for serving such content. Accordingly, network engineers have developed systems that allow “content peering” between two or more CDNs. Generally, content peering allows two or more CDNs to share facilities (e.g., content routers and content engines) and to collectively serve the same content, referred to as peered content. In a typical peering relationship, one CDN called the primary CDN has content that its operator/owner to would like to make available to end users using content engines belonging to one or more other CDNs, called secondary CDNs. All CDNs (i.e., both primary and secondary) can benefit from this arrangement since the primary can provide a better distribution outlet for content provided by content providers (i.e., customers of the primary CDN) while the secondary CDNs can make additional content easily and quickly accessible to customers of the secondary CDN, which are the end users or subscribers at client computer systems.
Two or more CDNs in a peering relationship typically adhere to a peering policy or peering service level agreement that indicates how each CDN is to peer content. As an example, the peering agreement or relationship may indicate that either CDN (i.e., the primary or any of the secondary) can have the right to terminate the peering relationship at any time without gaining permission from the other CDNs. This termination might be complete such that the entire peering relationship ends and thus a secondary CDN need not peer content for the primary, or only certain content may no longer be peered by a secondary CDN in which case this secondary CDN can continue to peer and serve other content on behalf of the primary CDN. The peering policy can also govern such things as billing and volume tracking criteria for content, bandwidth requirements, and the like.
In a typical content peering relationship between two or more content distribution networks (e.g., a primary and one or more secondary or peering CDNs), end users of some client computer systems may be customers of the primary CDN while other users of other client computer systems may be customers of a secondary CDN that peers content on behalf of the primary CDN. Accordingly, customers of a secondary CDN ought to receive content from devices such as web servers or web caches belonging to their respective secondary CDN, while other end users operating respective client computer systems ought to receive their content from devices belonging to the primary CDN or from caches belonging to another CDN peering content on behalf of the primary CDN (i.e., in which case there are multiple secondary or peering CDN's in a peering relationship with the primary CDN).